parallelism in rust
std::thread::spawnでのthreadは'staticなlifetimeを持つのでより短い参照を渡すことができない。
-> 実際はjoin()が呼ばれた時点で全てのthreadが終了しているはずだがrustでは最悪の状況を考えている。
handle.join().unwrap()?
-> パニックは安全でスレッド単位で起こる。依存スレッドに広がっていくことはない。あるスレッドでのパニックはエラーのResultとして報告。
Rayon
Rayonでのワークスティール手法によるスレッド間負荷の動的な調整
（rustは効率性によりネイティブスレッドだが（CPU１コア２月１つのワーカスレッド）、たくさんのタスクに分割しワークスティールによりバランスを見てスレッドに分散）
-> par_iter()とか。
crossbeamのscoped threadを低レベルで用いているので自動joinによりスレッド間での参照共有をサポート（例えば、reduce_withの並行処理がリターンするまでに終了することが保証されているから）
Given that adding rayon doesn't give us a speedup on zoomzoom due to the overhead cost of coordinating threads, let's close this issue.
dalek
Accelerating Edwards Curve Arithmetic with Parallel Formulas
Even faster Edwards curves with IFMA
Flexible precomputation for verification checks
Investigate Curve25519-dalek for faster bulletproofs
Tokio Thread Pool
Future
future: 計算の状態を取り扱うtrait
lazy: 遅延処理用の関数をラップ
task: 非同期世界のスレッド
Executor: taskの実行
work stealingでキューのバランスを保ち複数のワーカースレッドを用いれる
spawn: taskの実行待ちキューに追加
waker: executorにporing可能であることを通知
tokio_threadpool
https://gyazo.com/66c76f9db38b51e5d67994eb8c3895ff
tokio_threadpool (config pool_size)
https://gyazo.com/a07b9d222b7107a4da48bcba2aec72bb
future_cpu_pool
https://gyazo.com/a55699c62942a6fc37f18bb223e17dc5
benchmark
https://gyazo.com/1a129e4fd7f1a458484c1badd79d7b13
epoch-based garbage collection
あるスレッドで削除されるオブジェクトに対して他のスレッドで参照をする可能性があるのですぐに削除できない。epoch-based GCでは効率的に参照がなくなってから削除されるメカニズムを提供。
Arc::new(Mutex::new(0))
atomicな参照カウント -> 複数スレッド間で直接共有しても安全
排他ロック
threadpoolのfifo vs lifo vs edf
rustのArcの内部構造
rustのArcについてその2
rustのMutexの内部構造